Businesses can have large, complex processes that sometimes require input from different people, departments, or even companies before a given process is considered “completed.” For example, processing an order for a production line could possibly involve input from a purchasing department (purchase raw materials), a design team (to design the product), the assembly department (make the product), a quality control team (test the product), a sales department (to sell what is produced), etc. Each of these teams may have many different subtasks to be completed for the process as a whole to move forward. Manually checking a process through a check list, verbal communication, or the like is generally inefficient and increases the likelihood of errors in work flow (e.g., because the defined process is not conformed to). One technique that companies can use to increase the efficiency of executing a process includes implementing business process automation, e.g., by describing the process in terms of a business process model. Of course it will be appreciated that the present invention is not limited to business process modeling, but may well be used in other scenarios, such as the systems engineering of complex technical products. For example, the development process of a vehicle is nowadays largely model-based. In such a scenario, various vehicle components may be modeled on a system-wide level defining the main mechanical components (e.g., chassis, engine, power train, etc.) as well as electric/electronic components (e.g., rain sensors, speed-limiters, embedded processors, and the related software). Further, the individual vehicle components are themselves defined by more and more concrete technical models as the development process continues, ultimately leading to a variety of technical component models on different levels of abstraction, but yet interrelated. Other technical applications of certain example embodiments may include, for example, technical manufacturing processes or processes that define a flow of steps to be performed by technical equipment, such as robotized automation equipment for conducting a manufacturing process.
Processes can be modeled in various notations—one of the most popular ones is Business Process Model and Notation (BPMN). BPMN is more or less technical and can be transformed into an executable format and executed by, for example, an ARIS (Architecture of Integrated Information Systems) Process Governance (APG) server that may be available from the assignee of the instant application. Another type of notation is called EPC (Event-Driven Process Chain). In certain respects this notation may be easier and/or more intuitive for certain types of users. For example, a business end user (e.g., a non-technical user) may be more comfortable designing a process in EPC as compared to BPMN. However, BPMN may be preferred for when the business process is executed/deployed. One way to provide both functionalities is to provide automatic transforms where EPC models may be transformed into BPMN models (and vice versa). Such transformations may be described in U.S. Publication No. 2009/0265684 and U.S. application Ser. Nos. 13/280,960 and 13/024,646, the entire contents of each which are hereby incorporated by reference. Accordingly, users may design models in EPC and provide the EPC notation to a system that transforms the EPC to BPMN (e.g., via a transformation such as EPC2BPMN). The resulting transform may then be passed to an ARIS process governance (APG) server that executes BPMN.
However, EPC is not without its downsides. For example, while EPC may be easier for certain users to operate in, it can become unwieldy because of the complexity and/or size of the process that is being modeled (e.g., as hundreds of steps may be involved in the process model for a moderately complex environment).
One technique for addressing the “too fine” granularity offered by EPC is to implement new levels of abstraction that allow designing processes by blocks instead of using single executable elements. However, this technique can have downsides. For example, the new level of abstraction can increase the complexity of the model such that it may become increasingly difficult (or in certain cases impossible) to transfer data between the different business services, which may themselves be executable processes. Moreover, this type of approach may not support the modularity of services in question but instead may require the review of the whole executable process after each change in data flow. As will be appreciated, this may potentially reduce the effectiveness of the initially provided abstraction.
An example of this issue is shown in FIG. 32. More specifically, diagram 3200 includes multiple large EPC models with their respective quite large and the individual elements. However, the individual elements are small and difficult to read. Further, if a user zooms too far in, the user may become lost and unable to grasp the purpose or “bigger picture” of the process being modeled. Moreover, simply zooming out (as shown in FIG. 32) does not provide a very good high level view in which the user can assess the purpose of the process. As explained above, one way to address this is to add a new layer of abstraction.
Thus, FIG. 32 also includes an abstraction layer that is used to hide the complexity. This is done through the use of a Value-Added Chain Diagram (VACD) 3202. The EPC models in the diagram 3200 are assigned to each chain, and the control flow is passed (e.g., the arrows in diagram 3200) via special event objects (process interfaces at the end/beginning of each model).
One issue with the VACD diagram approach is that it may not be possible to control or model the data flow within the EPC diagrams for each chain in some cases. This issue is shown in FIG. 33 where the VACD diagram does not “know” about the data flow dependencies (represented by the arrows in FIG. 33) from the EPC diagram.
In certain instances, problems may result from such an implementation. For example, if an activity fails during process execution on the server, the failure may not mean that the problem exists in the EPC model where the “problem” activity object is located. Instead, the problem may be in another EPC model that has propagated the problem up/down the chain of execution. Moreover, it may be not always be feasible to provide a workable chain (backed by an EPC model) because it may contain references to dataflow in another EPC. Further, it may not be possible to test each chain separately, and instead, the entire process may need to be tested. This lack of component testing may lead to long design and/or testing times for process development.
Thus, it will be appreciated that there is a need in the art for improved techniques of modeling business processes through various notation schemes such as, for example, EPC, BPMN, and the like. The problem of correct transition between different model levels is similarly severe in the above-mentioned systems engineering context. For example, strong interrelations may exist between the lower-abstraction (e.g., fine-grained) technical models of the vehicle components of an automobile and the higher-abstraction (e.g., more coarse-grained) component or overall vehicle models. This is because the vehicle components typically have multiple interaction points on the higher abstraction level that are reflected correctly in the lower-level models and vice versa—an example of which is an optical or radar-based distance sensor component that may be shared by both a software-based speed-limiter and an emergency breaking component. Such interrelations, as well as other feature interactions, can make the correct and consistent transition of model elements between different model levels more difficult.
Accordingly, in certain example embodiments, techniques (e.g., algorithms) for variable generation and population are provided. The generation and population of such variables may work and/or be provided by an “Automation diagram.” In certain example embodiments, the diagram may provide communication between independent executable blocks and/or may control dependencies between the blocks. In certain example embodiments, an automated implementation may be provided that interfaces between the different “blocks” (e.g., that may be complex business services) through automatic generation of atomic operations and linkage between the services via variables that are automatically created and/or filled with corresponding values.
Certain example embodiments may provide one or more of the following and/or other advantages:
Workable executable blocks of a process;
Modular business services that are “ready to run;”
Reduction in time and effort on debugging and testing of such processes; and
Simplification of process design and/or clear implementation for a user.
In certain example embodiments, a system for providing an automation diagram may be provided. In certain example embodiments, the generation of an automation diagram is done independently of the creation of an EPC model. In other words, automation diagrams may not be generated from the EPC model. In certain example embodiments, a data flow between automation chains may be generated automatically.
In certain example embodiments, a method of linking executable process to one another is provided. A base control flow model is provided that includes a plurality of components, with at least some of the components include one or more data fields. An automation model is provided that includes a plurality of blocks, with each said block being associated with a partial subset of the base control flow model and including indication(s) of data field(s) associated with the respective partial subset of the base control flow model. Relationships are defined between at least some of the indications of the data fields in the blocks of the automation model. A request to transform the base control flow model to a transformed control flow model is responded to by, for each block in the automation model: determining which indication(s) of the data field(s) in the block is/are output(s) for the block; determining, for each said output, a corresponding input for another one of said blocks; generating a new component in the transformed control flow model; creating a variable for the new component for each output for the block and for each input to the another one of said blocks; associating the created variables with one another to indicate a connection therebetween in accordance with the defined relationships represented in the automation model; and injecting the new component into the partial subset associated with the block.
In certain example embodiments, a system for linking executable processes to one another is provided. A storage medium is configured to store a base control flow model that includes a plurality of components, at least some of the components including one or more data fields. The storage medium is also configured to store an automation model that includes a plurality of blocks, each said block being associated with a partial subset of the base control flow model and including indication(s) of data field(s) associated with the respective partial subset of the base control flow model, wherein relationships are defined between at least some of the indications of the data fields in the blocks of the automation model. The system includes a processing system with at least one processor. The processing system is configured to respond to a request to transform the base control flow model to a transformed control flow model by, for each block in the automation model: determine which indication(s) of the data field(s) in the block is/are output(s) for the block; determine, for each said output, a corresponding input for another one of said blocks; generate a new component in the transformed control flow model; create a variable for the new component for each output for the block and for each input to the another one of said blocks; associate the created variables with one another to indicate a connection therebetween in accordance with the defined relationships represented in the automation model; and inject the new component into the partial subset associated with the block.
In certain example embodiments, a computer implemented method of linking segments of a base control flow process model that includes a plurality of components divided among the segments is provided. At least some of the plurality of components include one or more data fields. The segments include first and second segments which include first and second components, respectively and the first and second components include first and second data fields. A base automation model is created that includes a plurality of blocks, the plurality of blocks including at least a first block and a second block. A plurality of relationships is defined among the plurality of blocks of the base automation model, the defined plurality of relationships including a first relationship between the first block and the second block. The base automation model is associated with the base control flow process model to create a combined model including: associating each one of the segments of the base control flow model with a respective one of the plurality of blocks of the base automation model, the first and second segments associated, respectively, with the first and second blocks; and assigning at least some data fields of the at least some plurality of components respective components to the plurality of relationships, including assigning the first data field to the first relationship and assigning the second data field to the first relationship.
In certain example embodiments, a computer-implemented method of linking executable processes to one another is provided. A base control flow model is provided that includes a plurality of components, at least some of the components including one or more data fields. An automation model is provided that includes a plurality of blocks, each said block being associated with a partial subset of the base control flow model and including indication(s) of data field(s) associated with the respective partial subset of the base control flow model, wherein relationships are defined between at least some of the indications of the data fields in the blocks of the automation model. Responding to a request to transform the base control flow model to a transformed control flow model by, for at least one of the blocks in the automation model: a new component is generated in the transformed control flow model; and an anchor is created for the new component in accordance with the defined relationships represented in the automation model.
In certain example embodiments, generated variables may be linked to thereby define a data flow. Additionally, or alternatively, in certain example embodiments, processes or events may be linked. Accordingly, a link may be created between a created anchor in one component and a created anchor in another component.
Non-transitory computer readable storage mediums tangibly storing instructions for performing the above-summarized and/or other methods also are provided by certain example embodiments, as well as corresponding computer programs.
Certain example embodiments may include systems configured to implement out one or more of the above-summarized and/or other methods also are provided by certain example embodiments.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.